Plasma Cash

---.icon

概要

Basically, we can design a version of Plasma with the following modifications:

以下の変更を加えた Plasma が設計できる。

1. Every single deposit corresponds to a unique coin ID; tokens are indivisible and cannot be merged.

2. Instead of storing transactions in a binary Merkle tree in order of txindex, we require them to be stored in either a sparse simple Merkle tree or a patricia tree, with the index being the ID of the coin that is spent.

1. 全てのデポジットはユニークなコイン ID と対応させる

トークンは分割もできないし結合もできない

2. txindex 順の binary Merkle tree の代わりに sparse simple Merkle tree か Patricia tree を使用する

index は消費されたコイン ID となる

これにより、ユーザーがコインの正当性を幾分コンパクトに証明できるようになった。コインが double spent されていないことを検証するためには、

コインの履歴：コインがデポジットされてから発生した全てのトランザクション

proof of non-inclusion：全てのブロックがそのコインを消費したトランザクションを含んでいないことの証明

Hence, a Plasma operator could simply maintain connections with each user, and every time they create a block they would publish to them only the proofs, not any data related to coins that they do not own. It’s clearly the case that any data that is not part of these proofs could not be used to fraudulently exit or double-spend the user’s coin, so the user is safe. Because coins are non-fungible, successfully defrauding other users cannot allow the Plasma contract to turn into a fractional reserve, as is possible in minimal viable plasma.

よって、オペレータは単純にそれぞれのユーザーとのコネクションを維持し、ブロックを生成するごとにユーザーに対して proof を公開するだけでよい。コインに関連した他のデータを公開する必要はない、というか持たなくてよい。当然、proof に含まれないデータをオペレータが使うことはできないので、オペレータは不正な exit もできないし、ユーザーのコインを double spend することもできない。よって、ユーザーは安全。コインは non-fungible なので、他のユーザーをうまく騙しても、Plasma コントラクトのデポジットが分割されることはない。Minimal Viable Plasma ではこれが可能だった。

The Plasma chain operator could be sharded, so there is virtually no limit to the system’s scalability from the point of view of either the chain operator or the users, though the limitation that if Plasma-like systems (and channel systems) start processing a very high transaction load, mass challenge attacks may overflow the blockchain and prevent some users from exiting or responding to challenges still remain. This kind of setup seems ideal for very-high-throughput but low or medium-state applications, like micropayments and exchanges.

Plasma-like なシステム（やチャネルシステム）が大量のトランザクションを捌く場合に大量の challenge による攻撃がブロックチェーンをオーバーフローさせ、ユーザーの exit や challenge への反応をも妨げるという欠点は残っているが、オペレータは水平分割できるので、オペレータ的な観点でもユーザー的な観点でもシステムのスケーラビリティに実質的な制限はない。このような機構は、マイクロペイメントや取引所のような高スループットだが状態が少ない or 中程度なアプリケーションには理想的。

Additionally, we can remove the need for confirmations. We do this by having the following exit procedure:

加えて、以下のような exit プロセスを行えば confirmation が不要になる。

1. Anyone can exit their coin by providing the last two transactions in the coin’s ownership history (ie. the coin they are exiting C and its parent P( C )).

2. An exit can be challenged in three ways: (i) provide a proof of a transaction spending C, (ii) provide a proof of a transaction spending P( C ) that appears before C, (iii) provide a transaction C* in the coin’s history before P( C )

3. A challenge of type (i) and (ii) blocks the exit immediately. A challenge of type (iii) can be responded to by providing the direct child of C*, which must be either equal to or before P( C )

1. コインは直近 2 つのトランザクションを提出することで exit できる

すなわち、exit しようとしているコイン C と、その親コイン P(C) の存在が証明できればよい

2. exit には 3 つの方法で challenge できる

(i) C を使用するトランザクションが存在することを証明する

(ii) C 以前に P(C) を使用するトランザクションが存在することを証明する

(iii) P(C) 以前に C* が存在することを証明する

3. (i) と (ii) は exit を即座にブロックし、(iii) は C* の子を提出することで返答できる

C* の子は、P(C) もしくは P(C) 以前のコイン

This relies on honest users maintaining the key property that they never spend a coin until they have fully authenticated the entire history up to that coin. It could be the case that a Plasma chain starts including unavailable or invalid data while a transaction is in flight, in which case double spends or invalid spends could appear between P( C ) and C; the slightly more complicated exit mechanism takes this into account.

Addenda:

2. Confirmations could easily be removed from the scheme. The solution is effectively a design where there is one level of interactive history verification, and spending a coin effectively takes on the role of a confirmation. That is, withdrawing requires a proof of a coin C, and if someone challenges with an earlier coin, then you can provide the parent P(C ); they would then need to prove a coin spending P(C ) that comes earlier than C to challenge.

追記：

2. このスキームでは confirmation は不要。これは 1 階層のインタラクティブな履歴検証を用いた効率的な設計であり、コインの使用が confirmation に相当する。つまり、exit にはコイン C の proof が必要であり、誰かがそれ以前のコインでこれに challenge した場合、C の親コインである P(C) を提出することができる。さらにこれに challenge する場合は、C 以前に P(C) を使用して生まれたコインの存在を証明する必要がある。

---.icon

基本ルール

1 ブロックに同じコインを使用する複数のトランザクションが含まれる可能性

In my design, not possible. The transaction’s position in the Merkle tree must be the ID of the coin, so you cannot have two transactions in one block that spend the same coin.

vbuterin：自分が提案した設計だと、それは不可能。Merkle tree におけるトランザクションの位置はコインの ID でなければならないので、同じコインを使用する 2 つのトランザクションを 1 つのブロックの中に含めることはできない。

親チェーンでのデポジット管理

Would coin ID => denomination be stored as a mapping on the root chain?

non-inclusion proof

A non-inclusion proof is basically a proof that there exists an object at the given position in the Merkle tree, and this object is empty data.

vbuterin：non-inclusion proof は「Merkle tree のある位置に空のオブジェクトが存在することの証明」。

オペレータが保持するデータ

Does the operator even need to maintain connections with every coinholder? Could we put the storage burden on the chain operator, and have it provide the history validity proof to the recipient after a transaction is confirmed, at the same time it provides the Merkle path to the new coin? (Or on request of the coinholder, if they just need to prove possession to someone.) Then the only burden on the coinholder would be to verify their coin’s history at the time that they receive it, and to monitor the parent chain for attempted withdrawals of that coin.

danrobinson：オペレータは全てのコイン保有者とのコネクションを維持する必要はある？オペレータにストレージ負荷を担ってもらい、トランザクションが承認された後、履歴が正しいことの証明と新しいコインの Merkle path をコインの受け手に提供すればよいのでは（もしくは、誰かにコインの所有を証明する必要があるだけならば、コイン保有者の要求に応じてこれを行う）？そうすると、コイン保有者の負担は、コインを受け取った際にその履歴を検証することと、不正なコイン引き出しを防ぐために親チェーンを監視することだけになる。

I suppose that can work. Though the storage burden could be large, so operators may want to forget it after some short period of time.

vbuterin：それでも機能すると思う。ストレージ負荷が大きくなったとしたら、オペレータは一定期間が経過したらそれを放棄したくなるかもしれないけど。

---.icon

発展的な議論